Certificate Background
Existing TLS Certificate Practices
Certificates are currently deployed on IoT devices. Many gateways and IoT devices host both a HTTP and a HTTPS webserver for device onboarding and device management purposes. Users are most often directed to the HTTP administrative web server because the browser is unable to confirm the HTTPS webserver's certificate as secure and:
- The browser's aggressive security warnings disconcert users, leading to support calls.
- Many browsers (intentionally) make it quite difficult to "click through" past the warning to the "insecure" destination web page. (Indeed, browser vendors have made public statements that they wish they could completely remove the bypass mechanism).
Browsers have a trust store with the root and intermediate certificates from Root CA's. These Root CA's are bound by the rules set by the CA/Browser Forum. These rules guard the trustworthiness of the CA's. A padlock means that the website is signed by a CA that follows the rules for validation. CA/Browser Forum does not allow for the .local suffix to be signed.
7.1.4.2.1 Subject Alternative Name Extension The entry MUST NOT contain an Internal Name.
A solution that embraces the use of well-formed X.509 certificates will have to be combined with new browser behaviour.
Certificate Semantics and Security Bootstrap
When the browser connects to the gateway or end point device over HTTPS, the characteristics of the security established are determined by both the characteristics of the certificate being used, and the mechanism by which the certificate was provisioned on the device (viable methods of revocation are also relevant: OCSP stapling is currently preferred by publicly facing web services in order to reduce extra connections, and increase privacy).
In order to fully understand the qualities of the various solutions, it is worth outlining different types of certificates that are currently being used by IoT vendors, on their locally IoT device hosted configuration, and management web servers
Self-signed methods are in use in many deployed devices. This method generates the same strong warnings on current browsers.
These warnings could be made more distinct with browser changes.
The self-signed methods should be discouraged, the private key credentials can be obtained from the device.
Without the possibility of verification, the certificate can be recreated, spoofed and allow for man in the middle attacks.
The different scenarios for the certificate deployment types are as follow
0. No certificate (null)
In the simplest case there is no certificate and the website is hosted unencrypted.
This method is the de facto standard. It should be strongly discouraged. It fails to implement zero trust principles. It leaves critical information, in particular passwords, in the clear. It also is vulnerable to on-path attacks from other devices on the local LAN.
1. Non device unique - self-signed certificate (NU-S/S)
In this scenario the exact same certificate is embedded into devices where the same firmware is used. For instance printers from the same production line using a certificate which is copied onto all devices.
The certificate subject common name is the same as the issuer common name. The certificate is signed by itself. The common name can be arbitrary.
This method will fail the certificate verification under current CA/Browser Forum guidelines and would generate browser errors, until an exception is granted for the certificate.
This method is actively being used by some device manufacturers.
This method should be discouraged.
2. Non device unique - untrusted root-signed certificate (NU-U/S)
In this scenario the exact same certificate is embedded in the firmware of all products from the same production line.
The certificate is signed by an untrusted root.
By untrusted we mean the signing authority does not correspond to any authority recognised by convention in most web browsers.
It is not part of the trust chain, since it's not signed by a CA from the ROOT CA programs.
It has exactly the same user experience as NU-S/S (above)
3. Device unique - self-signed certificate (U-S/S)
In this scenario a public/private key pair is generated unique to this device.
This key pair could be generated in the factory, or during device initialisation.
The common name could be
- Arbitrary text: e.g. "pre-set certificate".
- MAC address: presumably unique to this device, but meaningless in current browser-based certificate check.
- Unique device address: e.g. GUID.
This class of certificate is self-signed.
It has exactly the same user experience as certificates that are non-device unique (as NU-S/S). This method will fail the certificate verification under current CA/Browser Forum guidelines and would generate browser errors, until an exception is granted for the certificate.
4. Device unique - self-signed root certificate (U-U/S)
This scenario is like scenario 2, but instead of self-signing the certificate, it is signed by a self-signed root.
The root certificate is not trusted in the browser.
For an enterprise that is dealing with a large number of devices from the same vendor (such as CCTV cameras), the adding of the untrusted root to the browser trust store has some advantages. An enterprise can even use Group Policy to push this anchor to the desktops of all relevant users.
For the home user, or smaller office, this method is otherwise indistinguishable from previous methods.
5. Device unique - locally-signed certificate (U-L/S)
This method is very similar to the method above (U-U/S), but the CA is a local entity. This could be a local application or a local gateway. This has the advantage over a cloud issued CA; the binding can happen locally, or in scenarios where there is no access to the public Internet.
In this method a certificate is signed by binding a unique device common name to a unique public key for this end point device.
This certificate is signed by a local entity, for example a mobile application or a gateway hosted signing service.
For this method to work:
- A Certificate Signing Request (CSR) must be generated as part of a one-off onboarding event.
- The CSR must be issued to and processed by the local service.
- The end point address used in the CSR, must resolve locally.
This method requires all the browsers on all the systems to add the gateway certificate that has signed all the local certificates.
This requires the certificates to remain local. This may cause problems when Internet servers start serving local certificates because the common name would not match the certificate.
The user would have to onboard a device into the home network. This could be done with a few easy to do steps that involve pressing a button or approving something in an application.
This method is supported by onboarding methods like: RFC8995 (BRSKI), and CSA MATTER protocol, and possibly the FIDO IoT onboarding mechanism.
The private key per device could be implemented at different points in the lifecycle.
No browser changes are required other than installing the local (home/enterprise) trust anchor. But, an existing browser can not trivially be used to do the onboarding.
Many of the solutions that will be discussed in the sections to follow, are examples of this solution
6. Device unique - CA root signed certificate (U-CA/S)
In this method a certificate is signed binding a unique device common name, to a unique public key on this end point device.
This certificate is signed by one of the trusted roots that the browsers use.
For this method to work:
- A Certificate Signing Request (CSR) must be generated as part of a one-off binding event.
- The CSR must be issued to and signed by one of the Root CAs.
- The common name used in the CSR must be publicly DNS resolvable, at least for the duration of the signing.
This method can be used without generating any browser security warnings. It is the method used by the flexible names Device DNS Name solution.
Device DNS Name provides a description of how we may achieve this method. This is still under investigation.
IoT Certificate Key Usage
Certificates have the parameter fields Key Usage (KU) and Extended Key Usage (EKU). These parameters describe the purpose of the certificate. For certificates used on the Internet the extended key usage is set to server authentication (id-kp 1): https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3
The Key Usage (KU) parameters of a normal certificate are typically Digital Signature, Key Encipherment and Client and Server Authentication. Other extended key usages are for client authentication, code signing, email protection and timestamping.
A new extended key usage dedicated to IoT could create a certificate class which would be allowed to be signed by a certification authority, vendor or any other authority. Browsers would be able to distinguish the certificate to be of local significance only.
A new EKU OID could be assigned as Local Device. Since this is different than a normal Server Authentication certificate, the browser can check that the connection is local and the certificate is signed by a device vendor or IoT authority (FIDO, Matter, CACERT) that acts as root for these certificates.
Non TLS Based Security
TLS enables encryption on the session layer, but it's possible to provide encryption for different protocols in different layers of the stack.
If the device is in possession of a public/private key pair, the device may sign one or more tokens, relating to the status of the devices.
In addition the device may be in possession of tokens signed by externally recognised authorities containing the device's public key, which also express key information relating to the status of the device.
The only real difference here relates to the expression of the claim. For example, these claims could be rendered as JWT JSON Web Tokens or as COSE, the CBOR Object Signing and Encryption.
This security would run over HTTP or BLE transfer, using JavaScript code in the browser.
Alternative Root of Trust
To solve the problem of establishing a trusted secure connection between a browser and a locally hosted web server, we could look outside of traditional TLS certificate semantics and use alternative methods to negotiate a secure TLS session and represent the results of this negotiation.
There are multiple sources of such information from which security could be established. Some of these methods could work in isolation, others can be combined.
Each of these methods could complement, or replace the existing root of trust negotiation method.
The results of this security negotiation could be manifest in a classic X.509 certificate, in which case we may make use of Extended Key Usage (see below), it could be made manifest in a more complex key signing hierarchies (with multiple additional roots of trust) , or it could be made manifest in non-certificate based representation (see below).
When negotiating a TLS connection, using standard CA/Browser Forum guidelines, trust is established, using the following high-level logic:
It is entirely possible within our new proposed browser to fundamentally change, or at least enhance, the decision logic for making a decision.
For example:
- The browser may ask the target device whether it is in possession of a valid ownership voucher and accompanying device attestation token using FIDO infrastructure.
- The target device may respond using cryptographic artefacts from the eSIM layer.
In both these examples we are using alternative trust mechanisms and surfacing the cryptographic artefacts, in order to complete the TLS negotiation.
Cert/Key Storage
The creation of the private key must be well thought out key ceremony process that ensures the private key stays secure at all times and is created according to the standards. Throughout the lifecycle of the key, which is likely equal o the lifecycle of the device, the right technical precautions must be in place to prevent leaking of the private key.
For a typical TLS session between a browser and an internet server. The server must have access to the private key.
When an IoT device is the server and offers a TLS connection, it must also have access to the private key matching it's certificate.
For IoT devices this means two important things
- Best practice methods need to be advised/enforced, to reduce the impacts of per device private key leakage. For example, ensuing each device uses unique keys, and ensuring that the device stores these keys on trusted and ideally tamper proof hardware.
- The user needs to be aware they are dealing with a different security context. The private key assurances will never be the same as hosted servers, and therefore the risks are different. The connection to a bank is different to the connection to the configuration panel of a printer.